Field of the Invention
Embodiments of the present invention relate generally to graphics processing and, more specifically, to managing memory regions to support sparse mappings.
Description of the Related Art
A typical computer system includes a central processing unit (CPU) and a graphics processing unit (GPU). Some GPUs are capable of very high performance using a relatively large number of small, parallel execution threads on dedicated programmable hardware processing units. The specialized design of such GPUs usually allows these GPUs to perform certain tasks, such as rendering 3-D scenes, much faster than a CPU. However, the specialized design of these GPUs also limits the types of tasks that the GPU can perform. By contrast, the CPU is typically a more general-purpose processing unit and therefore can perform most tasks. Consequently, the CPU usually executes the overall structure of a software application and then configures the GPU to implement a graphics processing pipeline that transform 3-D images generated by the software application into rendered 2-D images.
During execution of the software application, representations of surfaces, known as “textures,” and other data associated with the graphics processing pipeline are typically stored in a graphics memory that is coupled to the GPU. However, increasingly, the complexity and resolution of textures exceeds the storage capacity of the graphics memory. Further, the software application often does not require access to all of the data included in all of the textures. Consequently, the software application may specify “sparse textures,” where only selected portions of the texture data are resident in the graphics memory.
One limitation to using sparse textures instead of textures that are fully resident in the graphics memory is that if the software application attempts to access sparse texture data that is not resident in the graphics memory, then a page fault is generated. The computer system may attempt to remedy the page fault by performing actions to map the data to an appropriate location in the graphics memory. However, remedying a page fault typically results in undesirable latency, often unacceptably degrading the performance of the software application. Alternatively, if the computer system does not remedy the page fault, then the software application may exhibit undesirable behavior, such as unexpectedly terminating.
In one approach to ensuring that the software application does not access sparse texture data that is not resident in the graphics memory, the software application generates an ancillary data structure that is designed to manage and track the sparse textures. In particular, the ancillary data structure represents the portions of the sparse textures that are resident in the graphics memory and the portions of the sparse textures that are not resident in the graphics memory. In operation, before accessing any data that is included in a sparse texture, the software application accesses the ancillary data structure. If the ancillary data structure indicates that the data is not resident in the graphics memory, then the software application proceeds without accessing the data.
Although this approach to managing sparse textures may avoid page faults associated with sparse textures, this approach does not necessarily address the performance degradation associated with spare textures. In particular, creating, maintaining, and traversing the ancillary data structure may significantly reduce the speed at which the software application executes. Further, incorporating an ancillary data structure into the code of the software application is tedious, time consuming, and error-prone. Notably, such an approach to managing sparse textures and, consequently, the limitations of this approach is generally applicable to managing sparse mappings associated with many types of graphics data (e.g., render targets).
Accordingly, what is needed in the art is a more effective technique for managing sparse mappings.